The committers listed above are authorized under a signed CLA.

• ✅ login: sh4shv4t / name: Shashvat Singh (c05ce4e, 58df91f)

Hi @lgritz, could you please have a look at this PR once? I have added the styling via a --dark command-line argument and will add the Preferences toggle and persistence logic once the styling is approved.

Sorry for the delay. I actually did test this but had mixed results.

I tried both on my personal Mac, and on my work Linux machine. In both cases, I saw minimal change, but maybe that's because I run in dark mode? Is it possible that Qt behavior is that the OS display choices explicitly choosing dark mode impose a dark palette and so this makes a visible change only if your OS and user choices are light mode? Or is it possible that it only makes a difference on certain window managers, or on MS Windows (which I couldn't test)?

Can you please post images showing the before and after appearance of iv that you expect with these changes?

It's 100% ok with me if all this effectively does is make it look dark when in light OS mode, but on effect if you've already selected dark mode and imposed a dark palette across the board. That still would be an acceptable patch.

My bigger concern, though, was that I -- totally coincidentally, I would not have consciously thought to try this -- tested it by displaying an image that happened to have an alpha channel and was transparent in some places, and this patch (versus main) definitely led to a different appearance in the "transparent" pixels. It must somehow change the background color? I would like for you to test this and track it down, we wouldn't this to inadvertently change/lighten the background pixel color for pixels with non-1.0 opacity.

@lgritz Thanks for the review!

Dark mode visibility: You're right in saying that if your OS is already in dark mode, the effect is minimal and that is consistent with Windows 11 too as per my tests. I believe this is because Qt inherits the system palette.

Transparent pixel background: I investigated this and believe I've found the root cause which was that the dark QPalette was applied in main() via app.setPalette() before ImageViewer was constructed. But the ImageViewer constructor then called QApplication::setPalette(m_palette) with a different palette (either QPalette(Qt::darkGray) or default), partially overwriting it. This race between two competing palettes could cause inconsistent widget backgrounds, which would be visible behind transparent pixels in the QOpenGLWidget.
The actual OpenGL clear color for transparent regions (glClearColor(0.05, 0.05, 0.05, 1.0) in ivgl.cpp) is hardcoded and completely independent of QPalette, so the image compositing itself isn't affected but the widget background leaking through at the edges could change appearance.

Fix: I've reworked the implementation to integrate --dark with the existing darkPalette preference system inside ImageViewer. The palette is now set up in a single place (the constructor), eliminating the conflict. I also upgraded the existing dark palette from the minimal QPalette(Qt::darkGray) to use the Fusion style with a proper dark color scheme, so the Preferences checkbox now produces the same improved result.

Please have a look let me know if this approach is okay and if these changes are okay to be merged. Also would you still like a before and after for Windows 11?